The mapping between identifiers and affine functions was introduced to
the ScheduleTreeMapping in a630d04 (ScheduleTreeElemMappingFilter:
store mapping between identifiers and functions, Wed May 16 17:44:08
2018 +0200), however the comparison operator was only comparing the
union_set filter_.  While the two representations are generally expected
to be equivalent, it is possible to modify them individually.  So we
need to also compare the mappings in ScheduleTreeMapping::operator==.

This method is abstract in the base class and is defined in derived
classes to perform the type comparison and, if types match, call the
class-specific comparison operator (or return true immediately for tree
nodes that are always considered equal to each other, e.g., sequences).
Its name indicates that that it applies to the current node only,
ignoring the subtree that may be rooted at this node.  It will be used
in the upcoming commits to use virtual methods instead of macro-based
dispatch on schedule node types.

The elemEquals function, as its name suggests, was introduced when
ScheduleTreeElement was a separate concept.  It was kept mostly intact
to minimize the changes when individual tree node classes were made
inheriting ScheduleTree instead.  Replace elemEquals with a call to the
virtual function nodeEquals that leverages polymorphism to perform
dynmaic dispatch instead of manual macro-based one.

In tree-like structures, the behavior of the default comparison
operators (operator== and operator!=) are not intuitive.  They may
compare individual tree nodes or the subtrees rooted at those nodes.
The current implementation made this confusion even worse where
ScheduleTree::operator== compared subtrees but ScheduleTree*::operator==
did not.  Replace comparison operators by type-safe non-virtual
overloads of nodeEquals in specific tree node classes.  Subtree
comparison can be performed by a dedicated method that will be
introduced next.

In tree-like structures, the behavior of the default comparison
operators (operator== and operator!=) is not intuitive.  They may
compare individual tree nodes or the subtrees rooted at those nodes.
Replace the equality comparison operator on ScheduleTree with the
treeEquals method, which makes it clear that subtrees are compared (as
opposed to nodeEquals introduced previously).

Removing the overloaded comparison operators may make it harder to use
standard containers and algorithms on ScheduleTrees.  However, the
caller is never supposed to operate on ScheduleTrees by-value, and
pointers are trivially comparable.  Internal functions may define and
use a comparator class with clear intended behavior when necessary.  For
external uses, explicitly-named functions offer a better alternative.